The committers listed above are authorized under a signed CLA.

• ✅ login: kendebacker / name: Kenneth DeBacker (a8db321)

Thanks for the PR.

I think this is a particular problem for the tests with "m" and "d", as "M" and "D" refer to something very different in the Datepicker dateFormat. The latter refer to day/month names while the former to dates/month numbers.

In that case, how come all tests pass on main?

Hi,

Thanks for taking the time to respond to my PR.

All tests pass at the moment because currently both capital and lowercase time periods for relative dates are being accepted

I am opting to change this to just lowercase time periods because that is the allowed input in the docs for relative dates

which I believe was set that way because for date formats there is significant difference in meaning between upper and lower case

I was planning to modify the code in 1588-1602 in another PR but thought I should wait to see if my thinking was correct.

Thanks for the info. At this stage of the project we're trying to avoid unnecessary breaking changes so I'm not sure we'd want to change the source here but I'll defer to @fnagel here who has way more experience with datepicker code.

Ah ok, thank you for explaining.

Apologies for straying outside the scope of this PR, but would a fix to #1971 be something worth pursuing? The issue is caused when the defaultDate, minDate, or maxDate setting option is given as a date string that is not in the specified dateFormat, the year is set 2028 and no error is thrown.

I was thinking that some code could be added to ensure that if the defaultDate, minDate, or maxDate is given as a date string that it is in the specified format, or else alert the user, as the user is not being alerted to the inconsistency in formatting.

Thanks again for taking the time to respond. I am looking to get experience contributing to open-source, but if if the project stage is not ideal for this, no worries

@kendebacker The issue sounds worth fixing, I think, but I'd still prefer to hear Felix's opinion first. 🙂 This is holiday time so let's wait a bit for his answer, perhaps in 2023.

Ok sounds good, thanks @mgol , happy holidays!

Hi @kendebacker, hi @mgol! Happy new year!

I'm not that familiar with the Datepicker code as I only worked on the never published rewrite of it (Calendar and Datepicker 2.0).

Anyway, I don't see why we should test with other values than documented. So the current code of the PR seems valid to me. We might want to think about testing both (upper and lowercase) as both are supported. @mgol What do you think?

At this stage of the project we're trying to avoid unnecessary breaking changes so I'm not sure we'd want to change the source here

Yes. As long as changing the actual code doesn't fix a bug, we should not touch it IMO.

Regarding a fix for #1971 - sure, why not :-)

@kendebacker sorry for the delay; landed now!

Thanks @mgol !